Add sample workflow templates to playground editor#16745
Merged
Conversation
Add a dropdown selector in the header bar with 5 agentic workflow templates sourced from githubnext/agentics: Hello World, Issue Triage, CI Doctor, Contribution Guidelines Checker, and Daily Repo Status. Selecting a sample replaces the editor content and auto-compiles. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This pull request adds a dropdown selector to the playground editor header that allows users to choose from five sample agentic workflow templates. The templates are sourced from the githubnext/agentics repository and include practical examples like Issue Triage, CI Doctor, Contribution Guidelines Checker, and Daily Repo Status, in addition to the existing Hello World workflow.
Changes:
- Added a dropdown select element in the editor header with five workflow template options
- Moved the Hello World default content into a SAMPLES object with four additional comprehensive workflow templates
- Added event handler to load selected templates into the editor with automatic compilation
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| docs/public/editor/index.html | Added select dropdown UI element in header bar between separators for template selection |
| docs/public/editor/editor.js | Refactored default content into SAMPLES object containing five workflow templates and added change event listener for template selection |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| 1. Select appropriate labels for the issue from the provided list. | ||
|
|
||
| 2. Retrieve the issue content using the \`get_issue\` tool. If the issue is obviously spam, or generated by bot, or something else that is not an actual issue to be worked on, then add an issue comment to the issue with a one-sentence analysis and exit the workflow. |
There was a problem hiding this comment.
Missing article before "bot". The phrase "or generated by bot" should be "or generated by a bot" for proper grammar.
|
|
||
| <div class="header-separator flex-shrink-0" style="width: 1px; height: 24px; background: var(--borderColor-default, var(--color-border-default));"></div> | ||
|
|
||
| <select class="form-select select-sm color-bg-subtle" id="sampleSelect" style="max-width: 220px; font-size: 12px;"> |
There was a problem hiding this comment.
The select element is missing an aria-label attribute for accessibility. This is important for screen reader users to understand the purpose of the dropdown. Consider adding aria-label="Select workflow template" or similar.
Suggested change
| <select class="form-select select-sm color-bg-subtle" id="sampleSelect" style="max-width: 220px; font-size: 12px;"> | |
| <select class="form-select select-sm color-bg-subtle" id="sampleSelect" aria-label="Select workflow template" style="max-width: 220px; font-size: 12px;"> |
Comment on lines
+31
to
+315
| 'issue-triage': `--- | ||
| description: | | ||
| Intelligent issue triage assistant that processes new and reopened issues. | ||
| Analyzes issue content, selects appropriate labels, detects spam, gathers context | ||
| from similar issues, and provides analysis notes including debugging strategies, | ||
| reproduction steps, and resource links. | ||
|
|
||
| on: | ||
| issues: | ||
| types: [opened, reopened] | ||
| reaction: eyes | ||
|
|
||
| permissions: read-all | ||
|
|
||
| network: defaults | ||
|
|
||
| safe-outputs: | ||
| add-labels: | ||
| max: 5 | ||
| add-comment: | ||
|
|
||
| tools: | ||
| web-fetch: | ||
| github: | ||
| toolsets: [issues] | ||
| lockdown: false | ||
|
|
||
| timeout-minutes: 10 | ||
| --- | ||
|
|
||
| # Agentic Triage | ||
|
|
||
| You're a triage assistant for GitHub issues. Your task is to analyze issue #\${{ github.event.issue.number }} and perform some initial triage tasks related to that issue. | ||
|
|
||
| 1. Select appropriate labels for the issue from the provided list. | ||
|
|
||
| 2. Retrieve the issue content using the \`get_issue\` tool. If the issue is obviously spam, or generated by bot, or something else that is not an actual issue to be worked on, then add an issue comment to the issue with a one-sentence analysis and exit the workflow. | ||
|
|
||
| 3. Next, use the GitHub tools to gather additional context about the issue: | ||
|
|
||
| - Fetch the list of labels available in this repository. Use 'gh label list' bash command to fetch the labels. | ||
| - Fetch any comments on the issue using the \`get_issue_comments\` tool | ||
| - Find similar issues if needed using the \`search_issues\` tool | ||
| - List the issues to see other open issues in the repository using the \`list_issues\` tool | ||
|
|
||
| 4. Analyze the issue content, considering: | ||
|
|
||
| - The issue title and description | ||
| - The type of issue (bug report, feature request, question, etc.) | ||
| - Technical areas mentioned | ||
| - Severity or priority indicators | ||
| - User impact | ||
| - Components affected | ||
|
|
||
| 5. Write notes, ideas, nudges, resource links, debugging strategies and/or reproduction steps for the team to consider relevant to the issue. | ||
|
|
||
| 6. Select appropriate labels from the available labels list: | ||
|
|
||
| - Choose labels that accurately reflect the issue's nature | ||
| - Be specific but comprehensive | ||
| - Select priority labels if you can determine urgency | ||
| - Only select labels from the provided list above | ||
|
|
||
| 7. Apply the selected labels using the \`update_issue\` tool. | ||
|
|
||
| 8. Add an issue comment with your analysis: | ||
| - Start with "Agentic Issue Triage" | ||
| - Provide a brief summary of the issue | ||
| - Include any debugging strategies or reproduction steps if applicable | ||
| - Suggest resources or links that might be helpful | ||
| - Use collapsed-by-default sections in the GitHub markdown to keep the comment tidy. | ||
| `, | ||
|
|
||
| 'ci-doctor': `--- | ||
| description: | | ||
| Automated CI failure investigator that triggers when monitored workflows fail. | ||
| Performs deep analysis of GitHub Actions workflow failures to identify root causes, | ||
| patterns, and provide actionable remediation steps. | ||
|
|
||
| on: | ||
| workflow_run: | ||
| workflows: ["CI"] | ||
| types: | ||
| - completed | ||
| branches: | ||
| - main | ||
|
|
||
| if: \${{ github.event.workflow_run.conclusion == 'failure' }} | ||
|
|
||
| permissions: read-all | ||
|
|
||
| network: defaults | ||
|
|
||
| safe-outputs: | ||
| create-issue: | ||
| title-prefix: "\${{ github.workflow }}" | ||
| labels: [automation, ci] | ||
| add-comment: | ||
|
|
||
| tools: | ||
| cache-memory: true | ||
| web-fetch: | ||
|
|
||
| timeout-minutes: 10 | ||
| --- | ||
|
|
||
| # CI Failure Doctor | ||
|
|
||
| You are the CI Failure Doctor, an expert investigative agent that analyzes failed GitHub Actions workflows to identify root causes and patterns. | ||
|
|
||
| ## Current Context | ||
|
|
||
| - **Repository**: \${{ github.repository }} | ||
| - **Workflow Run**: \${{ github.event.workflow_run.id }} | ||
| - **Conclusion**: \${{ github.event.workflow_run.conclusion }} | ||
| - **Run URL**: \${{ github.event.workflow_run.html_url }} | ||
| - **Head SHA**: \${{ github.event.workflow_run.head_sha }} | ||
|
|
||
| ## Investigation Protocol | ||
|
|
||
| **ONLY proceed if the workflow conclusion is 'failure' or 'cancelled'**. Exit immediately if the workflow was successful. | ||
|
|
||
| ### Phase 1: Initial Triage | ||
|
|
||
| 1. **Verify Failure**: Check that \${{ github.event.workflow_run.conclusion }} is failure or cancelled | ||
| 2. **Get Workflow Details**: Use \`get_workflow_run\` to get full details of the failed run | ||
| 3. **List Jobs**: Use \`list_workflow_jobs\` to identify which specific jobs failed | ||
| 4. **Quick Assessment**: Determine if this is a new type of failure or a recurring pattern | ||
|
|
||
| ### Phase 2: Deep Log Analysis | ||
|
|
||
| 1. **Retrieve Logs**: Use \`get_job_logs\` with \`failed_only=true\` to get logs from all failed jobs | ||
| 2. **Pattern Recognition**: Analyze logs for error messages, stack traces, dependency failures, infrastructure issues, timeout patterns, and resource constraints | ||
| 3. **Extract Key Information**: Primary error messages, file paths and line numbers, test names, dependency versions, timing patterns | ||
|
|
||
| ### Phase 3: Root Cause Investigation | ||
|
|
||
| 1. **Categorize Failure Type**: | ||
| - Code Issues, Infrastructure, Dependencies, Configuration, Flaky Tests, External Services | ||
|
|
||
| 2. **Deep Dive Analysis**: | ||
| - For test failures: Identify specific test methods and assertions | ||
| - For build failures: Analyze compilation errors and missing dependencies | ||
| - For infrastructure issues: Check runner logs and resource usage | ||
|
|
||
| ### Phase 4: Reporting | ||
|
|
||
| 1. **Create Investigation Report** as a GitHub issue including: | ||
| - Executive Summary | ||
| - Root Cause analysis | ||
| - Reproduction Steps | ||
| - Recommended Actions | ||
| - Prevention Strategies | ||
| `, | ||
|
|
||
| 'contribution-check': `--- | ||
| description: | | ||
| Reviews incoming pull requests to verify they comply with the repository's | ||
| contribution guidelines. Checks CONTRIBUTING.md and similar docs, then either | ||
| labels the PR as ready or provides constructive feedback on what needs to be | ||
| improved to meet the guidelines. | ||
|
|
||
| on: | ||
| pull_request: | ||
| types: [opened, edited, synchronize] | ||
| reaction: eyes | ||
|
|
||
| permissions: read-all | ||
|
|
||
| network: defaults | ||
|
|
||
| safe-outputs: | ||
| add-labels: | ||
| allowed: [contribution-ready] | ||
| max: 1 | ||
| add-comment: | ||
| max: 1 | ||
|
|
||
| tools: | ||
| github: | ||
| toolsets: [default] | ||
| lockdown: false | ||
|
|
||
| timeout-minutes: 10 | ||
| --- | ||
|
|
||
| # Contribution Guidelines Checker | ||
|
|
||
| You are a contribution guidelines reviewer for GitHub pull requests. Your task is to analyze PR #\${{ github.event.pull_request.number }} and verify it meets the repository's contribution guidelines. | ||
|
|
||
| ## Step 1: Find Contribution Guidelines | ||
|
|
||
| Search for contribution guidelines in the repository. Check these locations in order: | ||
|
|
||
| 1. \`CONTRIBUTING.md\` in the root directory | ||
| 2. \`.github/CONTRIBUTING.md\` | ||
| 3. \`docs/CONTRIBUTING.md\` or \`docs/contributing.md\` | ||
| 4. Contribution sections in \`README.md\` | ||
| 5. Other repo-specific docs like \`DEVELOPMENT.md\`, \`HACKING.md\` | ||
|
|
||
| Use the GitHub tools to read these files. If no contribution guidelines exist, use general best practices. | ||
|
|
||
| ## Step 2: Retrieve PR Details | ||
|
|
||
| Use the \`get_pull_request\` tool to fetch the full PR details including: | ||
| - Title and description | ||
| - Changed files list | ||
| - Commit messages | ||
|
|
||
| ## Step 3: Evaluate Compliance | ||
|
|
||
| Check the PR against the contribution guidelines for: | ||
|
|
||
| - **PR Title**: Does it follow the required format? Is it clear and descriptive? | ||
| - **PR Description**: Is it complete? Does it explain the what and why? | ||
| - **Commit Messages**: Do they follow the required format (if specified)? | ||
| - **Required Sections**: Are all required sections present (e.g., test plan, changelog)? | ||
| - **Documentation**: Are docs updated if required by guidelines? | ||
|
|
||
| ## Step 4: Take Action | ||
|
|
||
| **If the PR meets all contribution guidelines:** | ||
| - Add the \`contribution-ready\` label to the PR | ||
| - Optionally add a brief welcoming comment acknowledging compliance | ||
|
|
||
| **If the PR needs improvements:** | ||
| - Add a helpful comment that includes: | ||
| - A friendly greeting (be welcoming, especially to first-time contributors) | ||
| - Specific guidelines that are not being met | ||
| - Clear, actionable steps to bring the PR into compliance | ||
| - Links to relevant sections of the contribution guidelines | ||
| - Do NOT add the \`contribution-ready\` label | ||
| `, | ||
|
|
||
| 'daily-repo-status': `--- | ||
| description: | | ||
| Creates daily repo status reports. Gathers recent repository activity | ||
| (issues, PRs, discussions, releases, code changes) and generates engaging | ||
| GitHub issues with productivity insights, community highlights, and | ||
| project recommendations. | ||
|
|
||
| on: | ||
| schedule: daily | ||
| workflow_dispatch: | ||
|
|
||
| permissions: | ||
| contents: read | ||
| issues: read | ||
| pull-requests: read | ||
|
|
||
| network: defaults | ||
|
|
||
| tools: | ||
| github: | ||
| lockdown: false | ||
|
|
||
| safe-outputs: | ||
| create-issue: | ||
| title-prefix: "[repo-status] " | ||
| labels: [report, daily-status] | ||
| --- | ||
|
|
||
| # Daily Repo Status | ||
|
|
||
| Create an upbeat daily status report for the repo as a GitHub issue. | ||
|
|
||
| ## What to include | ||
|
|
||
| - Recent repository activity (issues, PRs, discussions, releases, code changes) | ||
| - Progress tracking, goal reminders and highlights | ||
| - Project status and recommendations | ||
| - Actionable next steps for maintainers | ||
|
|
||
| ## Style | ||
|
|
||
| - Be positive, encouraging, and helpful | ||
| - Use emojis moderately for engagement | ||
| - Keep it concise - adjust length based on actual activity | ||
|
|
||
| ## Process | ||
|
|
||
| 1. Gather recent activity from the repository | ||
| 2. Study the repository, its issues and its pull requests | ||
| 3. Create a new GitHub issue with your findings and insights | ||
| `, |
There was a problem hiding this comment.
The 'issue-triage', 'ci-doctor', 'contribution-check', and 'daily-repo-status' templates are missing the optional 'name:' field in their frontmatter, while 'hello-world' includes it. While the name field is optional and defaults to the filename, these templates would benefit from having explicit names for consistency and clarity in the playground editor, especially since they're not actual files. Consider adding name fields like 'name: issue-triage', 'name: ci-doctor', etc. to match the hello-world pattern.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Test plan
🤖 Generated with Claude Code